Adds a utility to create a span v2 envelope from a `SerializedSpan`
array + tests.

Note: I think here, the "v2" naming makes more sense than the
`StreamSpan` patter we use for user-facing functionality. This function
should never be called by users, and the envelope is type `span` with
content type `span.v2+json`

ref #17836

This PR adds span JSON conversion and serialization helpers for span
streaming:

* `spanToStreamedSpanJSON`: Converts a `Span` instance to a JSON object
used as intermediate representation as outlined in
#19100
* Adds `SentrySpan::getStreamedSpanJSON` method to convert our own spans
  * Directly converts any OTel spans
  * This is analogous to how `spanToJSON` works today.
* `spanJsonToSerializedSpan`: Converts a `StreamedSpanJSON` into the
final `SerializedSpan` to be sent to Sentry.

This PR also adds unit tests for both helpers.

ref #17836

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Jan Peer Stöcklmair <jan.peer@sentry.io>

This PR adds a simple span buffer implementation to be used for
buffering streamed spans.

Behaviour:
- buckets incoming spans by `traceId`, as we must not mix up spans of
different traces in one envelope
- flushes the entire buffer every 5s by default
- flushes the specific trace bucket if the max span limit (1000) is
reached. Relay accepts at max. 1000 spans per envelope
- computes the DSC when flushing the first span of a trace. This is the
latest time we can do it as once we flushed we have to freeze the DSC
for Dynamic Sampling consistency
- debounces the flush interval whenever we flush
- flushes the entire buffer if `Sentry.flush()` is called
- shuts down the interval-based flushing when `Sentry.close()` is called
- [implicit] Client report generation for dropped envelopes is handled
in the transport

Methods:
- `add` accepts a new span to be enqueued into the buffer
- `drain` flushes the entire buffer
- `flush(traceId)` flushes a specific traceId bucket. This can be used
by e.g. the browser span streaming implementation to flush out the trace
of a segment span directly once it ends.

Options:
- `maxSpanLimit` - allows to configure a 0 < maxSpanLimit < 1000 custom
span limit. Useful for testing but we could also expose this to users if
we see a need
- `flushInterval`- allows to configure a >0 flush interval

Limitations/edge cases:
- No maximum limit of concurrently buffered traces. I'd tend to accept
this for now and see where this leads us in terms of memory pressure but
at the end of the day, the interval based flushing, in combination with
our promise buffer _should_ avoid an ever-growing map of trace buckets.
Happy to change this if reviewers have strong opinions or I'm missing
something important!
- There's no priority based scheduling relative to other telemetry
items. Just like with our other log and metric buffers.
- since `Map` is [insertion order
preserving](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#description),
we apply a FIFO strategy when`drain`ing the trace buckets. This is in
line with our [develop
spec](https://develop.sentry.dev/sdk/telemetry/telemetry-processor/backend-telemetry-processor/#:~:text=The%20span%20buffer,in%20the%20buffer.)
for the telemetry processor but might lead to cases where new traces are
dropped by the promise buffer if a lof of concurrently running traces
are flushed. I think that's a fine trade off.

ref #19119